Pipeline, March/April 1995, vol.6, no.2
Copyright © 1995 Silicon Graphics
There are many misconceptions surrounding multi-pipe systems. This article will provide a list of multi-pipe systems that are currently supported by SGI, and attempt to clear up some of the confusion with regard to other SGI products. It will then explain some restrictions inherent in the X window system that end users may encounter, as well as the different configurations possible with a multi-pipe system that a system administrator might find useful. Finally, some multi-pipe IRIS GL programming caveats will be discussed for the benefit of the SGI developer.
What is a Multi-pipe System
A multi-pipe graphics option is one where the system has more than one graphics pipeline. Multiple graphics pipes provide more available screen area than single-pipe systems. They are often used in situations where multiple full screen views are essential to a simulation, or in applications which require detailed high resolution graphics output viewed in conjunction with a complex user interface.
______ _____
| | ------ _/| |
| | --> ( gfx () --> |_ | |
| | ------ \|____|
| CPU | _____
| | ------ _/| |
| | --> ( gfx () --> |_ | |
|_____| ------ \|____|
Figure 1. Multi-pipe graphics system with 1 CPU, 2 graphics
pipes and 1 monitor for each pipe
Table 1 illustrates that most, but not all, multi-pipe configurations
will use the same type of graphics hardware for all of the pipes in
the configuration. These systems are called homogeneous multi-pipe
systems. Newer additions to the family of multi-pipe graphics
options, such as the Extreme/XL configuration, allow an extra twist
to the dual-pipe equation in that the graphics hardware for each pipe
is from a completely different hardware architecture. This type of
configuration, in which graphics pipes are not all of the same
hardware type, is called a heterogeneous or non-homogeneous
multi-pipe configuration.
Graphics System Type Configuration Skywriter 2 VGXT graphics pipes Dual-headed Indigo 2 Entry Indigo graphics pipes Power Series multi-pipe RealityEngine 2 RealityEngine graphics pipes Onyx multi-pipe 2 or 3 RealityEngine graphics RealityEngine pipes Dual-headed Indigo2 XL/XL 2 XL (NG1) graphics pipes Dual-headed Indigo2 1 XL (NG1) graphics pipe and XL/Extreme 1 Extreme (GR2) graphics pipe Triple Keyboard Option, Onyx 2 or 3 RealityEngine graphics (TKO) pipes Table 1. Supported multi-pipe configurations
Multi-pipe vs. Multi-channel
There are two types of graphics configurations which have as their chief characteristic multiple monitors or heads attached to the same system: multi-pipe graphics options and the multi-channel options (MCOs are also known as video splitters).
_____ _____
| | ---------- _/| |
| | --> ( Extreme () --> |_ | |
| | ---------- \|____|
| CPU | _____
| | ------ _/| |
| | --> ( XL () --> |_ | |
|_____| ------ \|____|
Figure 2. Heterogeneous multi-pipe graphics systems
Multi-pipe graphics options have dedicated rendering hardware, or a
graphics pipeline, for each monitor or head of the multi-pipe system,
each with its own frame buffer. Thus, the terms dual-head or
multi-head describing graphics options are commonly interchanged with
the terms dual-pipe or multi-pipe.
Multi-channel options differ from multi-pipe graphics options in that the video outputs of an MCO all stem from a single graphics pipeline with a single frame buffer. The term multi-channel refers to systems where multiple video outputs each display a different section of the frame buffer. Since extra monitors are required for a multi-channel option, MCOs are sometimes seen as multi-head systems as well.
______ ______ _____
| | | | _/| |
| | | | --> |_ | |
| | ------ | | \|____|
| CPU | --> ( gfx () --> | MCO | _____
| | ------ | | _/| |
| | | | --> |_ | |
|_____| |_____| \|____|
Figure 3. Multi-channel system. One graphics pipe drives an array of
monitors with an MCO
However, it is important to note that the term multi-pipe is not
synonymous with multi-channel. This also implies that it is possible
to have a multi-pipe system with a multi-channel option for each
pipe. In fact, such configurations exist where a multi-pipe
RealityEngine has one or more MCOs with each MCO being driven off a
RealityEngine pipeline (as in Figure 4).
______ ______ _____
| | | | _/| |
| | | | --> |_ | |
| | ------ | | \|____|
| | --> ( gfx () --> | MCO | _____
| | ------ | | _/| |
| | | | --> |_ | |
| | |_____| \|____|
| CPU | ______ _____
| | | | _/| |
| | | | --> |_ | |
| | ------ | | \|____|
| | --> ( gfx () --> | MCO | _____
| | ------ | | _/| |
| | | | --> |_ | |
|_____| |_____| \|____|
Figure 4. Multi-pipe, multi-channel system. Two graphics
pipes each drive an MCO and their respective monitor arrays
The output of the gfxinfo(1G) command is useful to see whether or not
a system is a multi-pipe system or not. A multi-pipe system would
produce gfxinfo output similar to the following:
% /usr/gfx/gfxinfo
Graphics board 0 is "GR2" graphics.
Managed (":0.0") 1280x1024
8 GEs, 2 REs, 24 bitplanes, 4 auxplanes, 4 cidplanes, Z-buffer
GR2 revision 6, VB2.0
HQ2.1 rev A, GE7 rev B, RE3.1 rev A, VC1 rev B, MC rev C
19" monitor
Graphics board 1 is "NG1" graphics.
Managed (":0.1") 1280x1024
24 bitplanes, NG1 revision 3, REX3 revision B, VC2 revision A
MC revision C,xmap9 revision A,cmap revision C,bt445 revision A
Display 1280x1024 @ 60Hz, monitor id 15
In a multi-pipe system, more than one graphics board is listed with
details about the graphics option, such as the type of graphics for
each board. The fact that this particular system has a different
graphics type for each board makes it a heterogeneous dual-pipe
system.
A single-pipe system with a multi-channel option might display gfxinfo output similar to the following:
% /usr/gfx/gfxinfo
Graphics board 0 is "RE" graphics.
Managed (":0.0") 1280x1504
MCO Display 0 640x480 @ 60Hz, origin (0, 0)
MCO Display 1 640x480 @ 60Hz, origin (640, 0)
MCO Display 2 1280x1024 @ 60Hz, origin (0, 480)
8 GE (GE8 rev. 0x7) 2 RM4 boards
Small pixel depth
10-bit RGB pixels
Driving Multi-Channel Option
Video Boards and Multi-pipe Systems
Video boards are also options that have more than one head associated with them. However, like the multi-channel option, video boards typically connect to one graphics pipe. Table 2 describes which video options could be used with particular multi-pipe graphics configurations and whether or not the resulting combination is supported. Refer to the Installation Guide for the specific video option for more details.
Multi-Pipe Video Support Graphics Option Status Dual-Head Indigo Indigo Video not supported Indigo2 XL/XL Indigo2 Video not supported Indigo2 XL/XL Galileo Video not supported Indigo2 XL/Extreme Indigo2 Video not supported Indigo2 XL/Extreme Galileo Video not supported PowerSeries Multi-Pipe RealityEngine Sirius Video supported for each pipe Onyx Multi-Pipe RealityEngine Sirius Video supported for each pipe PowerSeries Multi-Pipe RealityEngine MCO supported for each pipe Onyx Multi-Pipe RealityEngine MCO supported for each pipe PowerSeries Multi-Pipe RealityEngine MCO plus Sirius supported for each pipe* Onyx Multi-Pipe RealityEngine MCO plus Sirius supported for each pipe* Table 2. Supported Video Options and Multi-Pipe Configurations * Because of hardware limitations, only one board, either the MCO or Sirius Video can be connected to a given RealityEngine pipe.
Restrictions on End Users
To understand some of the caveats in configuring and using a multi-pipe system, it helps to understand some of the underlying X Window System concepts that make a multi-pipe system a software entity as well as a hardware entity.
Key X Window System Concepts
The X Window System has clearly defined concepts of what comprises a Display, a Screen, and a Window. The data structures involved in the implementation of these concepts impose constraints on what can be done with combinations of each.
Although the Xlib Programming Manual definition of an X screen allows for broader possibilities, for the sake of discussion, this article will treat the notion of a screen the way the SGI X server treats it; as an instantiation of a single graphics pipe. In other words, a screen is a means for directly addressing pixels in the frame buffer of a graphics pipe. It is helpful to keep in mind that a screen is a software abstraction, independent of its hardware implementation. Whether the graphics hardware configuration is an Indy or a RealityEngine pipe with an MCO, the X window system sees each as an independent screen. An X window is a rectangular subregion of a screen against which X rendering is clipped and X events are registered.
An X display, however, is the collection of one (or more) X screen(s) together with a keyboard and a mouse. The typical X configuration is a single X server managing a single X display with a single screen. For a dual-pipe configuration, the traditional picture of a display changes. There is now a single X display with one keyboard and mouse and two screens. Again, it is helpful to keep in mind that the notion of a display in the X window system is also a software abstraction.
______ _____
| | ------ _/| |
| CPU | --> ( gfx () --> |_ | :0 |
| | ------ \|____|
| | ________ __
| | |------ | /||\
| | --> |#### # #| | |
|_____| |#### # #| |__|
--------_____|
\______________________/
an X display
Figure 5. An X Display consists of at least one graphics
pipe, keyboard and mouse
The X server is the program which performs operations directly on an
X display on behalf of X client programs. There is always one and
only one X server for every X display. It is the X server's job to
manage the operations of the entire display, such as drawing to X
windows on the various screens of the display, or reporting keystroke
or mouse events to an interested X client.
X Displays with Multiple Screens
It is often not immediately apparent to users how they can get an application to be displayed on an alternate screen. Most users will have their DISPLAY variable set to :0, the default setting which displays applications to the first screen (often the only screen), of the local host's X display. In addition, many X applications will accept a -display command line option as an alternate means of specifying the display of choice. Both methods can be extended beyond the traditional <hostname>:0 in order to denote which screen on a multi-pipe display a given application will be shown.
________ __
_____ _____ _____ |------ | /||\
_/| | _/| | _/| | |#### # #| | |
|_ |:0.0| |_ |:0.1| |_ |:0.2| |#### # #| |__|
\|____| \|____| \|____| ---------____|
^ ^ ^ ^
| | | |
======= ======= ======= |
| pipe0 | | pipe1 | | pipe2 | |
|_______| |_______| |_______| |
^ ^ ^ |
| | | |
---------------------------------------------------
/ X server \
\___________________________________________________/
Figure 6. A single X server controlling three graphics
pipes as independent screens as part of its display
Many users are unaware that a suffix of .# can be appended to the
DISPLAY variable or the -display option which will determine the
screen on which an X application will display. The # is a number
which corresponds to a particular screen, with the screens being
numbered starting with 0. A DISPLAY variable or -display option of
quark:0.0 will display to the first screen of the X display on a
system called quark. A setting of :0.1 will display on the second
screen of the local X display. To get a complete listing of the all
the screens for any given display use the xlistscrns(1) command. An X
display with three screens would show the following output for
xlistscrns:
% /usr/bin/X11/xlistscrns :0.0 :0.1 :0.2Because the DISPLAY variable is a shell environment variable, applications or scripts spawned from other applications or scripts will inherit the DISPLAY variable from their parent. For this reason, applications launched from the toolchest(1X) appear on the screen from which they were launched. If a user has trouble getting an X application to appear on the screen they want, check the DISPLAY variable and how it may have been inherited from its parent processes.
Multiple Screens and Individual X Windows
Once an X application is displayed on a screen, many users are disappointed to find that the application cannot be moved from one screen to the next. To understand just why this windowing limitation exists, it is helpful to be aware of how different constructs within the X window system are limited in their interactions.
A visual in the X window system is a data structure that describes the pixel characteristics of a window, such as how the bits in a given pixel should be translated into intensity and color. Although it is true that the same visual types exist across the various screens of a homogeneous multi-pipe system, the designers of the X window system chose to have instantiations of visuals conceptually tied to individual X screens. In general, the most important concept to remember is that the X visual of a window is required by the X window system to be determined before an X window is created. In addition, while the X window is in existence, the visual type cannot be changed.
It is entirely possible, especially in the heterogeneous case, for a screen on a multi-pipe system to have different display capabilities, and thus different visual types, that another screen does not. A simple example of a configuration that would not have the same display characteristics would be if one pipe were only capable of display in black-and-white and another pipe were capable of color.
Since (by this article's definition) any given X software abstraction of a screen can be associated with a single hardware graphics pipe, it follows that an X window can only be associated with a single hardware graphics pipe. In order for an application to look as if it were moving a window from one screen to another, completely separate windows would have to be created for the application on the different screens.
This same windowing limitation also contributes to some other anomalies seen on multi-pipe systems. For instance, not only can a window not be moved as a whole from one screen to another, but it can also not be bridged across two screens. Also, a given application must be written in a way (which will be described later) that enables it to operate successfully across an X display with multiple screens. This implies that applications that open multiple X windows should not necessarily be expected to have the ability to automatically position or move these windows around the different screens of a multi-pipe display, since the only hint of which screen to display their windows on comes from the single DISPLAY environment variable.
Configuring Multi-pipe Systems
Configuration of the X servers is done via the file /usr/lib/X11/xdm/Xservers. Normally, a single-pipe system has a single entry in it for the X display called :0.
:0 secure /usr/bin/X11/X -bs -nobitscale -c \ -pseudomap 4sight -solidroot sgilightblue \ -cursorFG red -cursorBG whiteThe Xservers file can only be edited by root. After modifying this file, the changes to the X server will not take place until xdm(1), the program which manages the login process and server initialization, is reset. The most convenient way to have these changes take effect is to first make sure all users are logged off the graphics console, and issue the following commands as root:
# /usr/gfx/stopgfx; /usr/gfx/startgfx & For more information on these two commands, refer to the manual pages for stopgfx(1G) and startgfx(1G).
Relative Positioning of Screens
By default, a multi-pipe system is configured so that screen 0 is the left most screen, with each additional screen logically positioned to the right of the previous one. With the monitors of the corresponding screens lined up in the same logical fashion, the cursor will leave a screen at its right edge and enter the next sequentially numbered screen at its left edge.
----- _____ _____
| X | -------- _/| |/| |
| s | --> ( pipe0 () --> |_ |:0.0| |:0.1|
| e | -------- \|____|\|____|
| r | ^
| v | -------- |
| e | --> ( pipe1 () ________________/
| r | --------
-----
Figure 7. Default monitor configuration. Screen 0 is
to the left of screen 1
Some customers require additional freedom in configuring the way the
X server sees the pipes logically positioned. The easiest way to
change how the Xserver, Xsgi(1) sees the screens positioned is to add
the -stacked option to the line in the file
/usr/lib/X11/xdm/Xservers. The -stacked option will now position
screen 0 as the bottom-most screen as opposed to the left-most
screen, with additional screens logically positioned above the
previous one. Now, as the cursor leaves the top edge of screen 0, it
enters screen 1 from its bottom edge.
:0 secure /usr/bin/X11/X -bs -nobitscale -c \
-pseudomap 4sight -solidroot sgilightblue \
-cursorFG red -cursorBG white -stacked
----- _____
| X | -------- _/| |
| s | --> ( pipe0 ()- ->|_ |:0.1|
| e | -------- \ / \|____|
| r | X _____
| v | -------- / \ _/| |
| e | --> ( pipe1 ()- ->|_ |:0.0|
| r | -------- \|____|
-----
Figure 8. Stacked monitor configuration.
Screen 0 is beneath screen 1.
Sometimes situations exist in which the placement of monitors for
graphics pipes cannot accommodate the default or stacked
configurations. For these situations, there is the -hw option to
Xsgi, which provides a way to manipulate whether the output from a
particular graphics board is logically above or below, to the right
or left of a neighbor, for each screen. For example, the following
line in the file /usr/lib/X11/xdm/Xservers would specify that screen
0 is logically above display 1:
:0 secure /usr/bin/X11/X -bs -nobitscale -c \
-pseudomap 4sight -solidroot sgilightblue \
-cursorFG red -cursorBG white -hw \
board=0,below=1 -hw board=1,above=0
----- _____
| X | -------- _/| |
| s | --> ( pipe0 () --> |_ |:0.0|
| e | -------- \|____|
| r | _____
| v | -------- _/| |
| e | --> ( pipe1 () --> |_ |:0.1|
| r | -------- \|____|
-----
Screen 9. Specialized monitor configuration.
Screen 0 is above screen 1
The value assigned to below (or above) corresponds to the number of
the board (or graphics pipe or screen) that is logically below it;
this value is not used as true or false. It is also possible to have
multiple screens where each is initialized with a different default
visual (or preferred pixel characteristics) using the -hw option.
Refer to the manual page for Xsgi(1) for more details regarding the
-hw option.
Configuring Multiple X Displays on Multi-pipe Systems
A frequent question from customers is whether purchasing another keyboard will enable them to turn their dual-pipe system into two independent displays on the same workstation. In most cases, such a configuration is only theoretically possible. Even though there would be two screens, each with independent graphics hardware, there is still a big problem; there is no place to plug in the extra keyboard. Recently, however, new hardware has become available for Onyx systems that makes this configuration a reality for Onyx owners.
The Triple Keyboard Option (TKO) is unique among the multi-pipe systems in that it provides the extra hardware to attach the extra keyboards and mice provided with it. Under the model described above, it's possible for any one of the TKO keyboards and mice to be grouped with any combination of the pipes (screens) to make completely separate X displays. Thus, it is possible to have three different X servers running on the same system, each managing a different keyboard, mouse and graphics pipe. It is also possible to configure the TKO to have one single-pipe display and another dual-pipe display.
None of these extra displays are possible without having both the TKO hardware and the extra RealityEngine pipes. It should also be noted that no extra hardware is needed for X Input Extension devices such as digitizing tablets, dials and buttons, spaceballs, or trackballs.
For a TKO system running multiple displays, a configuration line is added to the file /usr/lib/X11/xdm/Xservers for each new X server to be introduced. Since what is now changing is the number of X servers, as opposed to the number of screens, each new X server must have a display number other than :0 assigned to it. Typically, this is done by naming the new X servers :1 and :2.
The new X servers also need to be told which graphics pipe to manage with which keyboard, since the default settings were only sufficient for the X server to use without a TKO. The -boards option to Xsgi tells the X server which graphics board to use, while the -devdir option delineates a directory where the input devices for the keyboard and mouse can be found. By default, an X server will use all available graphics boards for -boards and /dev/input for -devdir. The default behavior is that however many graphics boards a system may have, every single graphics board will be incorporated with the standard console keyboard to comprise the X display. A sample configuration of the Xservers file of a TKO might look like this:
:0 secure /usr/bin/X11/X -boards 0 -devdir \ /dev/input -bs -nobitscale -c -pseudomap \ 4sight -solidroot sgilightblue -cursorFG \ red -cursorBG white :1 secure /usr/bin/X11/X -boards 1 -devdir \ /dev/input1 -bs -nobitscale -c -pseudomap \ 4sight -solidroot sgilightblue -cursorFG \ red -cursorBG white :2 secure /usr/bin/X11/X -boards 2 -devdir \ /dev/input2 -bs -nobitscale -c -pseudomap \ 4sight -solidroot sgilightblue -cursorFG \ red -cursorBG whiteWhere /dev/input, /dev/input1, and /dev/input2 are directories containing files called keyboard and mouse which are symbolic links to the appropriate device files. Links for X Input Extension devices files should also reside in the /dev/input<#> directory for the appropriate display. Refer to the manual page for Xsgi(1) and the Triple Keyboard Option Installation Guide for more details. Also, for more information about configuring xdm or the Xservers file, refer to the X Window System Administrator's Guide.
Displaying to these new X servers is as easy as setting the DISPLAY environment variable or the -display option to :1 or :2. Screen extensions or hostname additions such as quark:1.1 work as expected where appropriate.
Changing Monitor Output Timing
As explained above, X applications will take as the pointer to the intended screen of display either the DISPLAY environment variable or the -display command line argument. However, when it comes to changing the monitor timing (or Video Output Formats; vofs) of multi-pipe systems with the setmon(1G) command, only the DISPLAY environment variable is followed. The -display functionality is part of any X application, however, setmon is not an X application and does not parse the command line for this argument. Changing the timing of both screen 0 and screen 1 could be accomplished using the commands below. Note that setmon will only change the monitor timing (or vof) of one pipe at a time.
# /bin/su - # setenv DISPLAY :0.0 # /usr/gfx/setmon 60HZ # setenv DISPLAY :0.1 # /usr/gfx/setmon 60HZ
Programming Issues for Multi-pipe Systems
The following section will address common questions programmers encounter when developing software for multi-pipe systems. A working knowledge of compilers, IRIS GL, and Xlib are assumed.
When programming for a multi-pipe system, the first thing one needs to know is how to open windows for rendering on different screens. In a purely IRIS GL program, getgdesc(GD_NSCRNS)(3G) will return the number of screens available on the current X display. The scrnselect(3G) function is used before a winopen(3G) command to specify the screen on which the window should be opened. Refer to the manual page for scrnselect(3G) for details.
In an Xlib or mixed-model program, there are two ways to open windows on different screens. The first method, although not always the best, is the most popular. A call to the function XOpenDisplay(3X11) is made to establish a separate server connection for each screen. When an X window is created, the connection corresponding to each screen is used as the Display pointer for the creation of the window.
#include <X11/Xlib.h>
/* First method of opening windows on */
/* 2 different screens */
/* Not Recommended */
Display *display0,*display1;
Window window0, window1;
display0 = XOpenDisplay(":0.0");
display1 = XOpenDisplay(":0.1");
window0 = XCreateSimpleWindow(display0,\
DefaultRootWindow(display0), \
0,0,400,400,0,0,0);
window1 = XCreateSimpleWindow(display1,\
DefaultRootWindow(display1),\
0,0,400,400,0,0,0);
XMapWindow(display0,window0);
XMapWindow(display1,window1);
This method is not recommended. Explicitly enumerating a string as
the display to be opened in XOpenDisplay removes control from the
user. Another equally inappropriate variation on this method includes
parsing the DISPLAY environment variable and adding the screen suffix
within the program. Although this is poor programming practice, this
method and its variations do indeed work.
The second and preferred method is to open a single connection to the display and create the X window as a child of the root window for each screen.
#include <X11/Xlib.h> /* Second method of opening windows on */ /* 2 different screens */ /* Recommended */ Display *display; Window window0, window1; display = XOpenDisplay(NULL); window0 = XCreateSimpleWindow(display,\ RootWindow(display,0), 0,0,400,400,0,0,0); window1 = XCreateSimpleWindow(display, \ RootWindow(display,1), 0,0,400,400,0,0,0); XMapWindow(display,window0); XMapWindow(display,window1);This method is a little better than the previous one in that the DISPLAY environment variable is used with XOpenDisplay, thus allowing users to choose their display. Also, only a single connection to the X server is used, since XOpenDisplay is called only once.
A combination of these methods uses the DISPLAY variable for use in one of the XOpenDisplay calls and the value of another environment variable (with a name like OTHER_DISPLAY) for the other XOpenDisplay call to specify the connection to the other screen. This method has the advantage that the newly introduced variable can point to the X display of a system somewhere else on the network. A disadvantage to this method is that if an application is being run on a multi-pipe system, it does not need to open more than one connection to a given display to access all of its screens.
Problems Specific to Heterogeneous Pipes
When writing IRIS GL programs that might be run on heterogeneous multi-pipe machines, there are a few issues involving symbol name resolution within the libraries required for native IRIS GL platforms that should be taken into account. It should be noted that OpenGL programs do not have to worry about the same problems that IRIS GL programs do. OpenGL has built-in support for multiple graphics devices within a single library and can switch between them as needed when the application calls glXMakeCurrent(3G) for a given OpenGL graphics context.
Using IRIS GL, it is possible to open windows on different screens at the same time. However, within a single application running on a heterogeneous multi-pipe system, it is only possible to do IRIS GL rendering into windows residing on screens of the same graphics type. Note that a different instantiation of the same executable could run on a screen of a different graphics type; the restriction only applies to a single instance of a given application.
Heterogeneous multi-pipe graphics options were first introduced in IRIX 5.2 with the Indigo2 dual-pipe XL/Extreme. The new run-time linker (rld(1)) in IRIX 5.x enabled libraries stored as dynamic shared objects (DSO(5)) to be loaded at any point during the execution of a program. More specifically, it is possible for the IRIX 5.x rld to load a DSO and resolve references to function calls and variables within that DSO at times other than when the binary is first executed. This enables part of the IRIS GL initialization code to evaluate which type of graphics hardware is about to be used, and resolve the IRIS GL symbol names accordingly by using the DSO appropriate for the graphics type.
All of the rld linking happens transparently to the user. If a user opens up a single window on any one screen of a heterogeneous multi-pipe system, the IRIX 5.x rld is able to load the correct DSO without the user even having to think about the fact that there are two different pieces of graphics hardware in the system; the application displays correctly on either screen.
However, if a program which is to run on a heterogeneous dual-pipe system tries to open a window on more than one screen in IRIS GL, only the first screen and screens like it will succeed in obtaining the ability to render. Once a function reference is resolved in a particular DSO, IRIS GL will not resolve the reference again using a different DSO. Once an IRIS GL call is made to a screen of a particular graphics type, no other rendering can be done to screens of other graphics types from within the same instantiation of the application. This means that while the heterogeneous systems are out of luck, the homogeneous multi-pipe systems are not affected by the problem of symbol name resolution within DSOs because each screen uses the same DSO for rendering.
The only way to work around the problem of name resolution within DSOs of heterogeneous systems for IRIS GL programs is to have part or all of an application executing as separate instantiations for each screen. Constructing a multi-process application so that IRIS GL commands are done after a fork(2) or sproc(2) is not sufficient, since when a DSO is loaded, the processes will share the text address space containing the actual CPU instructions. Because it is necessary for the processes doing the IRIS GL rendering on the different pipes to execute completely different instructions, their text address space must be different, and therefore it becomes essential to have a separately launched program for each type of graphics pipe. This implies that some sort of interprocess communication would have to take place, but discussing this topic is beyond the scope of this article. For more information about inter-process communication, refer to the IRIX System Programming Guide, Chapter 5.
IRIX 4 Binaries on Heterogeneous Multi-pipes
There exists another problem for heterogeneous multi-pipes. When an IRIX 4.x IRIS GL binary is run on a heterogeneous multi-pipe system with the DISPLAY set to something other than screen 0, the error below occurs.
GL: this system has the wrong /usr/lib/libgl_s installed (is:GR2, needs:NG1) ...Exiting to avoid grief.In IRIX 4, binary compatibility across graphics platforms was achieved by means of static shared libraries as opposed to the dynamic shared objects (DSOs) of IRIX 5.x. Like the DSOs for IRIS GL, the shared libraries for IRIS GL used a common set of function calls as entry points into hardware specific graphics routines. Unlike DSOs, however, static shared libraries must all be linked at the beginning of execution. Consequently, the libgl_s can contain the IRIS GL calls for only one graphics type at a time.
References
Xlib Programming Manual, O'Reilly and Associates, ISBN 1-56592-002-3. Note that this book is also available on-line with InSight(1).
X Window System Administrator's Guide, O'Reilly and Associates, ISBN 0-937175-83-8.
IRIX System Programming Guide, available on-line with InSight.